数据仓库架构以及多维数据模型的设计
点击上方 "云祁QI"关注, “星标”一起成长
一、前言
作者最近看了《Hadoop构建数据仓库实践》这本书，收获很多，把一些关于数仓实践的心得整理出来，方便大家共同学习。
注：本文内容由作者摘自《Hadoop构建数据仓库实践》与其他相关参考资料，旨在方便大家参考学习，如您觉得侵犯了您的权益，请联系我们删除，谢谢！
二、数据仓库的定义
数据仓库是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合，用于对管理决策过程的支持。数据仓库本身并不“生产”任何数据，同时自身也不需要“消费”任何的数据，数据来源于外部，并且开放给外部应用使用。
三、数据仓库的特点
面向主题的：数据仓库都是基于某个明确的主题，仅需要与该主题相关的数据，其他的无关细节将会被去掉。
集成的：数据仓库里面的数据都是经过ETL（ Extract-Transform-Load 抽取-转换-加载）操作后被集中放到同一个数据源，数据仓库里的数据是来自于各种不同的数据源。
随时间变化的：关键数据隐式或者显示地随时间变化而变化。
数据相对稳定的：数据装入后一般只是进行查询操作，没有传统数据库的增删改操作。
总结：数据仓库就是整合多个数据源的历史数据进行细粒度的、多维的分析，可以有效地帮助高层管理者或者业务分析人员做出商业战略决策或商业报表。
四、数据仓库的作用
可以整合公司的所有业务，建立统一的数据中心。
分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果。
可以作为各个业务的数据源，形成业务数据互相反馈的良性循环。
可以提供数据报表，用于公司的决策等等。
数据处理大致可以分成两大类：
联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。
OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。
OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。OLTP 系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作。OLAP系统则强调数据分析，强调SQL执行市场，强调磁盘I/O，强调分区等。
五、数据仓库的架构
数据采集与分析：数据采集层的任务就是把数据从各种数据源中采集和存储到数据库上，期间有可能会做一些ETL（抽取extra，转化transfer，装载load ）操作。数据源种类可以有多种：
日志：所占份额最大，存储在备份服务器上 业务数据库：如Mysql、Oracle 来自HTTP/FTP的数据：合作伙伴提供的接口 其他数据源：如Excel等需要手工录入的数据 数据存储与分析
HDFS是大数据环境下数据仓库/数据平台最完美的数据存储解决方案。
离线数据分析与计算，也就是对实时性要求不高的部分，Hive是不错的选择。
使用Hadoop框架自然而然也提供了MapReduce接口，如果真的很乐意开发Java，或者对SQL不熟，那么也可以使用MapReduce来做分析与计算。
Spark性能比MapReduce好很多，同时使用SparkSQL操作Hive。
数据共享
前面使用Hive、MR、Spark、SparkSQL分析和计算的结果，还是在HDFS上，但大多业务和应用不可能直接从HDFS上获取数据，那么就需要一个数据共享的地方，使得各业务和产品能方便的获取数据。这里的数据共享，其实指的是前面数据分析与计算后的结果存放的地方，其实就是关系型数据库和NOSQL数据库。
数据应用
报表：报表所使用的数据，一般也是已经统计汇总好的，存放于数据共享层。
接口：接口的数据都是直接查询数据共享层即可得到。
即席查询：即席查询通常是现有的报表和数据共享层的数据并不能满足需求，需要从数据存储层直接查询。一般都是通过直接操作SQL得到。
六、数据仓库的要求
高效率：数据仓库的分析数据一般分为日、周、月、季、年等，可以看出，以日为周期的数据要求的效率最高，要求24小时甚至12小时内，客户能看到昨天的数据分析。由于有的企业每日的数据量很大，如果数据仓库设计的不好，需要延时一到两天才能显示数据，这显然是不能出现这种事情的。
数据质量高：数据仓库所提供的各种信息，肯定要准确的数据。数据仓库通常要经过数据清洗，装载，查询，展现等多个流程而得到的，如果复杂的架构会有更多层次，那么由于数据源有脏数据或者代码不严谨，都可以导致数据不准确或者有错误，如果客户看到错误的信息就可能导致分析出错误的决策，造成损失经济的损失。
扩展性：之所以有的大型数据仓库系统架构设计复杂，是因为考虑到了未来3-5年的扩展性，因为如果在未来需要扩展一些新的功能了，就可以不用重建数据仓库系统，就能很稳定运行。因为重建一个数据创库是比较耗费人力和财力。可扩展性主要体现在数据建模的合理性。
为了达到上述的要求，建立起一个高效率、高数据质量、良好的可扩展性，再加上为了提高建仓的速度，根据在实际生产环境中的经验的总结，于是就提出来了数据仓库的分层概念。
那么到底什么是数据仓库的分层？为什么要分成?数据仓库的分层的好处是什么呢？接下来将介绍关于数据仓库分层的一些概念。
七 、数据仓库分层
分层是数据仓库解决方案中，数据架构设计的一种数据逻辑结构 ，通过分层理念建立的数据仓库，它的可扩展性非常好，这样设计出来的模型架构，可以任意地增减、替换数据仓库中的各个组成部分。
用空间换时间，通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量冗余的数据。
如果不分层的话，如果源业务系统的业务规则发生变化将会影响整个数据清洗过程，工作量巨大。
通过数据分层管理可以简化数据清洗的过程，因为把原来一步的工作分到了多个步骤去完成，相当于把一个复杂的工作拆成了多个简单的工作，把一个大的黑盒变成了一个白盒，每一层的处理逻辑都相对简单和容易理解，这样我们比较容易保证每一个步骤的正确性，当数据发生错误的时候，往往我们只需要局部调整某个步骤即可。
八、数据仓库四个层次的划分
标准的数据仓库分层：ODS（临时存储层），PDW（数据仓库层），MID（数据集市层），APP（应用层）。
ODS：临时存储层，它和源系统数据是同构的，而且这一层数据粒度是最细的，这层的表分为两种，一种是存储当前需要加载的数据，一种是用于存储处理完后的数据。
PDW：数据仓库层，它的数据是干净的数据，是一致的准确的，也就是清洗后的数据，它的数据一般都遵循数据库第三范式，数据粒度和ODS的粒度相同，它会保存bi系统中所有历史数据。
MID：数据集市层，它是面向主题组织数据的，通常是星状和雪花状数据，从数据粒度来讲，它是轻度汇总级别的数据，已经不存在明细的数据了，从广度来说，它包含了所有业务数量。从分析角度讲，大概就是近几年。
App：应用层，数据粒度高度汇总，但不一定涵盖所有业务数据，只是MID层数据的一个子集。
8.1 ODS层
“面向主题的”，数据运营层是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就说传说中的ETL之后，装入本层。本层的数据，总体上大多是按照源头业务系统的分类方式而分类的。
例如这一层可能包含的数据表为：人口表（包含每个人的身份证号、姓名、住址等）、机场登机记录（包含乘机人身份证号、航班号、乘机日期、起飞城市等）、银联的刷卡信息表（包含银行卡号、刷卡地点、刷卡时间、刷卡金额等）、银行账户表（包含银行卡号、持卡人身份证号等）等等一系列原始的业务数据。这里我们可以看到，这一层面的数据还具有鲜明的业务数据库的特征，甚至还具有一定的关系数据库中的数据范式的组织形式。
但是，这一层面的数据却不等同于原始数据。在源数据装入这一层时，要进行诸如去噪（例如去掉明显偏离正常水平的银行刷卡信息）、去重（例如银行账户信息、公安局人口信息中均含有人的姓名，但是只保留一份即可）、提脏（例如有的人的银行卡被盗刷，在十分钟内同时有两笔分别在中国和日本的刷卡信息，这便是脏数据）、业务提取、单位统一、砍字段（例如用于支撑前端系统工作，但是在数据挖掘中不需要的字段）、业务判别等多项工作。
8.2 PDW层
数据仓库的主体，在这里从ODS层中获得的数据按照主题建立各种数据模型。例如以研究人的旅游消费为主题的数据集中，便可以结合航空公司的登机出行信息，以及银联系统的刷卡记录，进行结合分析，产生数据集。在这里，我们需要了解四个概念：维（dimension）、事实（Fact）、指标（Index）和粒度（ Granularity）。
PDM层：数据集市，从数据的时间跨度来说，通常是DW层的一部分，按照业务划分，如流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。
8.3 APP层
在这里，主要是提供给数据产品和数据分析使用的数据，一般会存放在es、mysql等系统中供线上系统使用，也可能会存在Hive或者Druid中供数据分析和数据挖掘使用。比如我们经常说的报表数据，或者说那种大宽表，一般就放在这里。
九、数据流向
数据来源层–> ODS层
这里其实就是我们现在大数据技术发挥作用的一个主要战场。我们的数据主要会有两个大的来源：
1、业务库：这里经常会使用sqoop来抽取，比如我们每天定时抽取一次。在实时方面，可以考虑用canal监听mysql的binlog，实时接入即可。
2、埋点日志：线上系统会打入各种日志，这些日志一般以文件的形式保存，我们可以选择用flume定时抽取，也可以用用spark streaming或者storm来实时接入，当然，flume+kafka是企业常用的组合。其它数据源会比较多样性，这和具体的业务相关，不再赘述。
ODS层–> APP层
这里面也主要分两种类型：
1、每日定时任务型：比如我们典型的日计算任务，每天凌晨算前一天的数据，早上起来看报表。这种任务经常使用Hive、Spark或者MR程序来计算，最终结果写入Hive、Hbase、Mysql、Es或者Redis中。
2、实时数据：这部分主要是各种实时的系统使用，比如我们的实时推荐、实时用户画像，一般我们会用Spark Streaming、Storm或者Flink来计算，最后会落入Es、Hbase或者Redis中。
PDW层 --> APP层
pdw分析完的数据，一般借助sqoop传输到关系型数据库如mysql，app层根据业务需要，以可视化的形式展示给决策层（BOSS）。
十、数据仓库模型设计基础
10.1 维度数据模型
维度数据模型简称维度模型（Dimensional modeling, DM），是一套技术和概念的集合，用于数据仓库设计。不同于关系数据模型，维度模型不一定要引入关系数据库。
在逻辑上相同的维度模型，可以被用于多种物理形式，比如维度数据库或是简单的平面文件。根据数据仓库大师Kimball的观点，维度模型是一种趋向于支持最终用户对数据仓库进行查询的设计技术，是围绕性能和易理解性构建的。尽管关系模型对于事务处理系统表现非常出色，但它并不是面向最终用户的。
事实和维度是两个维度模型中的核心概念。事实表示对业务数据的度量，而维度是观察数据的角度。事实通常是数字类型的，可以进行聚合和计算，而维度通常是一组层次关系或描述信息，用来定义事实。例如，销售金额是一个事实，而销售时间、销售的产品、购买的顾客、商店等都是销售事实的维度。维度模型按照业务流程领域
即主题域建立，例如进货、销售、库存、配送等。不同的主题域可能共享某些维度，为了提高数据操作的性能和数据一致性，需要使用一致性维度，例如几个主题域间共享维度的复制。术语“一致性维度”源自Kimball，指的是具有相同属性和内容的维度。
10.2 维度数据模型建模过程
维度模型通常以一种被称为星型模式的方式构建。所谓星型模式，就是以一个事实表为中心，周围环绕着多个维度表。还有一种模式叫做雪花模式，是对维度做进一步规范化后形成的。
一般使用下面的过程构建维度模型：
选择业务流程
声明粒度
确认维度
确认事实
这种使用四步设计法建立维度模型的过程，有助于保证维度模型和数据仓库的可用性。
1．选择业务流程
确认哪些业务处理流程是数据仓库应该覆盖的，是维度方法的基础。因此，建模的第一个步骤是描述需要建模的业务流程。例如，需要了解和分析一个零售店的销售情况，那么与该零售店销售相关的所有业务流程都是需要关注的。为了描述业务流程，可以简单地使用纯文本将相关内容记录下来，或者使用“业务流程建模标注”（BPMN）方法，也可以使用统一建模语言（UML）或其他类似的方法。
2．声明粒度
确定了业务流程后，下一步是声明维度模型的粒度。这里的粒度用于确定事实中表示的是什么，例如，一个零售店的顾客在购物小票上的一个购买条目。在选择维度和事实前必须声明粒度，因为每个候选维度或事实必须与定义的粒度保持一致。在一个事实所对应的所有维度设计中强制实行粒度一致性是保证数据仓库应用性能和易用性的关键。从给定的业务流程获取数据时，原始粒度是最低级别的粒度。建议从原始粒度数据开始设计，因为原始记录能够满足无法预期的用户查询。汇总后的数据粒度对优化查询性能很重要，但这样的粒度往往不能满足对细节数据的查询需求。不同的事实可以有不同的粒度，但同一事实中不要混用多种不同的粒度。维度模型建立完成之后，还有可能因为获取了新的信息，而回到这步修改粒度级别。
3．确认维度
设计过程的第三步是确认模型的维度。维度的粒度必须和第二步所声明的粒度一致。维度表是事实表的基础，也说明了事实表的数据是从哪里采集来的。典型的维度都是名词，如日期、商店、库存等。维度表存储了某一维度的所有相关数据，例如，日期维度应该包括年、季度、月、周、日等数据。
4．确认事实
确认维度后，下一步也是维度模型四步设计法的最后一步，就是确认事实。这一步识别数字化的度量，构成事实表的记录。它是和系统的业务用户密切相关的，因为用户正是通过对事实表的访问获取数据仓库存储的数据。大部分事实表的度量都是数字类型的，可累加，可计算，如成本、数量、金额等。
10.3 维度规范化
与关系模型类似，维度也可以进行规范化。对维度的规范化（又叫雪花化），可以去除冗余属性，是对非规范化维度做的规范化处理，在下面介绍雪花模型时，会看到维度规范化的例子。一个非规范化维度对应一个维度表，规范化后，一个维度会对应多个维度表，维度被严格地以子维度的形式连接在一起。实际上，在很多情况下，维度规范化后的结构等同于一个低范式级别的关系型结构。
设计维度数据模型时，会因为如下原因而不对维度做规范化处理：
规范化会增加表的数量，使结构更复杂。
不可避免的多表连接，使查询更复杂。
不适合使用位图索引。
查询性能原因。分析型查询需要聚合计算或检索很多维度值，此时第三范式的数据库会遭遇性能问题。如果需要的仅仅是操作型报表，可以使用第三范式，因为操作型系统的用户需要看到更细节的数据。
正如在前面关系模型中提到的，对于是否应该规范化的问题存在一些争论。总体来说，当多个维度共用某些通用的属性时，做规范化会是有益的。例如，客户和供应商都有省、市、区县、街道等地理位置的属性，此时分离出一个地区属性就比较合适。
10.4 维度数据模型的特点
易理解
相对于规范化的关系模型，维度模型容易理解且更直观。在维度模型中，信息按业务种类或维度进行分组，这会提高信息的可读性，也方便了对于数据含义的解释。简化的模型也让系统以更为高效的方式访问数据库。关系模型中，数据被分布到多个离散的实体中，对于一个简单的业务流程，可能需要很多表联合在一起才能表示。
高性能
维度模型更倾向于非规范化，因为这样可以优化查询的性能。介绍关系模型时多次提到，规范化的实质是减少数据冗余，以优化事务处理或数据更新的性能
可扩展
维度模型是可扩展的。由于维度模型允许数据冗余，因此当向一个维度表或事实表中添加字段时，不会像关系模型那样产生巨大的影响，带来的结果就是更容易容纳不可预料的新增数据。这种新增可以是单纯地向表中增加新的数据行而不改变表结构，也可以是在现有表上增加新的属性。基于数据仓库的查询和应用不需要过多改变就能适应表结构的变化，老的查询和应用会继续工作而不会产生错误的结果。但是对于规范化的关系模型，由于表之间存在复杂的依赖关系，改变表结构前一
定要仔细考虑。
10.5 星形模型（star schema）
星型模式是维度模型最简单的形式，也是数据仓库以及数据集市开发中使用最广泛的形式。
星型模式由事实表和维度表组成，一个星型模式中可以有一个或多个事实表，每个事实表引用任意数量的维度表。星型模式的物理模型像一颗星星的形状，中心是一个事实表，围绕在事实表周围的维度表表示星星的放射状分支，这就是星型模式这个名字的由来。
星型模式将业务流程分为事实和维度。事实包含业务的度量，是定量的数据，如销售价格、销售数量、距离、速度、重量等是事实。维度是对事实数据属性的描述，如日期、产品、客户、地理位置等是维度。一个含有很多维度表的星型模式有时被称为蜈蚣模式，显然这个名字也是因其形状而得来的。蜈蚣模式的维度表往往只有很少的几个属性，这样可以简化对维度表的维护，但查询数据时会有更多的表连接，严重时会使模型难于使用，因此在设计中应该尽量避免蜈蚣模式。
1）事实表
事实表记录了特定事件的数字化的考量，一般由数字值和指向维度表的外键组成。通常会把事实表的粒度级别设计得比较低，使得事实表可以记录很原始的操作型事件，但这样做的负面影响是累加大量记录可能会更耗时。事实表有以下三种类型：
事务事实表。记录特定事件的事实，如销售。
快照事实表。记录给定时间点的事实，如月底账户余额。
累积事实表。记录给定时间点的聚合事实，如当月的总的销售金额。一般需要给事实表设计一个代理键作为每行记录的唯一标识。代理键是由系统生成的主键，它不是应用数据，没有业务含义，对用户来说是透明的。
2）维度表
维度表的记录数通常比事实表少，但每条记录包含有大量用于描述事实数据的属性字段。维度表可以定义各种各样的特性，以下是几种最长用的维度表：
时间维度表。描述星型模式中记录的事件所发生的时间，具有所需的最低级别的时间粒度。数据仓库是随时间变化的数据集合，需要记录数据的历史，因此每个数据仓库都需要一个时间维度表。
地理维度表。描述位置信息的数据，如国家、省份、城市、区县、邮编等。
产品维度表。描述产品及其属性。
人员维度表。描述人员相关的信息，如销售人员、市场人员、开发人员等。
范围维度表。描述分段数据的信息，如高级、中级、低级等。
通常给维度表设计一个单列、整型数字类型的代理键，映射业务数据中的主键。业务系统中的主键本身可能是自然键，也可能是代理键。自然键指的是由现实世界中已经存在的属性组成的键，如身份证号就是典型的自然键。
3）优点
星型模式是非规范化的，在星型模式的设计开发过程中，不受应用于事务型关系数据库的范式规则的约束。星型模式的优点下：
简化查询。查询数据时，星型模式的连接逻辑比较简单，而从高度规范化的事务模型查询数据时，往往需要更多的表连接。
简化业务报表逻辑。与高度规范化的模式相比，由于查询更简单，因此星型模式简化了普通的业务报表（如每月报表）逻辑。
获得查询性能。星型模式可以提升只读报表类应用的性能。
快速聚合。基于星型模式的简单查询能够提高聚合操作的性能。
便于向立方体提供数据。星型模式被广泛用于高效地建立OLAP立方体，几乎所有的OLAP系统都提供ROLAP模型（关系型OLAP），它可以直接将星型模式中的数据当作数据源，而不用单独建立立方体结构。
4）缺点
星型模式的主要缺点是不能保证数据完整性。一次性地插入或更新操作可能会造成数据异常，而这种情况在规范化模型中是可以避免的。星型模式的数据装载，一般都是以高度受控的方式，用批处理或准实时过程执行的，以此来抵消数据保护方面的不足。
星型模式的另一个缺点是对于分析需求来说不够灵活。它更偏重于为特定目的建造数据视图，因此实际上很难进行全面的数据分析。星型模式不能自然地支持业务实体的多对多关系，需要在维度表和事实表之间建立额外的桥接表。
10.6 雪花模型（snowflake schema）
雪花模式是一种多维模型中表的逻辑布局，其实体关系图有类似于雪花的形状，因此得名。与星型模式相同，雪花模式也是由事实表和维度表所组成。
所谓的“雪花化”就是将星型模式中的维度表进行规范化处理。当所有的维度表完成规范化后，就形成了以事实表为中心的雪花型结构，即雪花模式。将维度表进行规范化的具体做法是，把低基数的属性从维度表中移除并形成单独的表。基数指的是一个字段中不同值的个数，如主键列具有唯一值，所以有最高的基数，而像性别这样的列基数就很低。在雪花模式中，一个维度被规范化成多个关联的表，而在星型模式中，每个维度由一个单一的维度表所表示。一个规范化的维度对应一组具有层次关系的维度表，而事实表作为雪花模式里的子表，存在具有层次关系的多个父表。星型模式和雪花模式都是建立维度数据仓库或数据集市的常用方式，适用于加快查询速度比高效维护数据的重要性更高的场景。这些模式中的表没有特别的规范化，
一般都被设计成一个低于第三范式的级别。
1）数据规范化与存储
规范化的过程就是将维度表中重复的组分离成一个新表，以减少数据冗余的过程。正因为如此，规范化不可避免地增加了表的数量。在执行查询的时候，不得不连接更多的表。但是规范化减少了存储数据的空间需求，而且提高了数据更新的效率。这点在前面介绍关系模型时已经进行了详细的讨论。
从存储空间的角度看，典型的情况是维度表比事实表小很多。这就使得雪花化的维度表相对于星型模式来说，在存储空间上的优势没那么明显了。举例来说，假设在220个区县的200个商场，共有100万条销售记录。星型模式的设计会产生1,000,200条记录，其中事实表1,000,000条记录，商场维度表有200条记录，每个区县信息作为商场的一个属性，显式地出现在商场维度表中。在规范化的雪花模式中，会建立一个区县维度表，该表有220条记录，商场表引用区县表的主键，有200条记录，事实表没有变化，还是1,000,000条记录，总的记录数是1,000,420（1,000,000+200+220）。在这种特殊情况（作为子表的商场记录数少于作为父表的区县记录数）下，星型模式所需的空间反而比雪花模式要少。如果商场有10,000个，情况就不一样了，星型模式的记录数是1,010,000，雪花模式的记录数是1,010,220，从记录数上看，还是雪花模型多。但是，星型模式的商场表中会有10,000个冗余的区县属性信息，而在雪花模式中，商场表中只有10,000个区县的主键，而需要存储的区县属性信息只有220个，当区县的属性很多时，会大大减少数据存储占用的空间。
有些数据库开发者采取一种折中的方式，底层使用雪花模型，上层用表连接建立视图模拟星型模式。这种方法既通过对维度的规范化节省了存储空间，同时又对用户屏蔽了查询的复杂性。但是当外部的查询条件不需要连接整个维度表时，这种方法会带来性能损失。
2）优点
雪花模式是和星型模式类似的逻辑模型。实际上，星型模式是雪花模式的一个特例（维度没有多个层级）。某些条件下，雪花模式更具优势：
一些OLAP多维数据库建模工具专为雪花模型进行了优化。
规范化的维度属性节省存储空间。
3）缺点
雪花模型的主要缺点是维度属性规范化增加了查询的连接操作和复杂度。相对于平面化的单表维度，多表连接的查询性能会有所下降。但雪花模型的查询性能问题近年来随着数据浏览工具的不断优化而得到缓解。和具有更高规范化级别的事务型模式相比，雪花模式并不确保数据完整性。向雪花模式的表中装载数据时，一定要有严格的控制和管理，避免数据的异常插入或更新。
10.7 事实星座模型（Fact Constellation）或星系模型（galaxy schema）
数据仓库由多个主题构成，包含多个事实表，而维表是公共的，可以共享，这种模式可以看做星型模式的汇集，因而称作星系模式或者事实星座模式。本模式示例如下图所示：
如上图所示，事实星座模式包含两个事实表：sales和shipping，二者共享维表。
十一、总结
事实星座模式是数据仓库最长使用的数据模式，尤其是企业级数据仓库（EDW）。这也是数据仓库区别于数据集市的一个典型的特征，从根本上而言，数据仓库数据模型的模式更多是为了避免冗余和数据复用，套用现成的模式，是设计数据仓库最合理的选择。当然大数据技术体系下，数据仓库数据模型的设计，还是一个盲点，探索中。
还想看更多？
戳下面查看更多干货👇
推荐阅读：
我是「云祁」，一枚热爱技术、会写诗的大数据开发猿，欢迎大家关注呀！